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ABSTRACT 



A diagnostic tool automatically collects and stores data 
indicative of a variability parameter, a mode parameter, a 
status parameter and a limit parameter associated with each 
of the different devices, loops or function blocks within a 
process control system, processes the collected data to 
determine which devices, loops or function blocks have 
problems that result in reduced performance of the process 
control system, displays a list of detected problems to an 
operator and then suggests the use of other, more specific 
diagnostic tools to further pinpoint or correct the problems. 
When the diagnostic tool recommends and executes a data 
intensive application as the further diagnostic tool, it auto- 
matically configures a controller of the process control 
network to collect the data needed for such a tool. 
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DIAGNOSTICS IN A PROCESS CONTROL integral (PID) control routine. The different function blocks 

SYSTEM within a process control system are configured to commu- 
nicate with each other (e.g., over a bus) to form one or more 

FIELD OF THE INVENTION process control loops, the individual operations of which are 

5 spread throughout the process and are, thus, decentralized. 

Tne present invention relates generally to process control with ^ advcnt of smart ficld dcvkxSj it fa morc { 

systems and, more particularly, to the automatic detection of lam lhan evef lQ be abk t0 quiddy ^gnose md correcl 

problems existing within function blocks, devices and loops problems that occur ^thin a process COQtrol systemj ^ the 

of a process control system. failure t0 detect and poorly per f orn iing loops; and 

DESCRIPTION OF THE RELATED ART 10 ^ ev ^ ces ^ ea ^ s t° sub-optimal performance of the process, 

which can be costly in terms of both the quality and the 

Process control systems, like those used in chemical, quantity of the product being produced. Many smart devices 

petroleum or other processes, typically include a centralized currently include self -diagnostic and/or calibration routines 

process controller communicatively coupled to at least one that can be used to detect and correct problems within the 

host or operator workstation and to one or more field devices 15 device. For example, the FieldVue and ValveLink devices 

via analog, digital or combined analog/digital buses. The made by Fisher Controls International Inc. have diagnostic 

field devices, which may be, for example valves, valve capabilities that can be used to detect certain problems 

positioners, switches and transmitters (e.g., temperature, within those devices and also have calibration procedures 

pressure and flow rate sensors), perform functions within the that can be used to correct problems, once detected, 

process such as opening or closing valves and measuring 20 However, an operator must suspect that a problem exists 

process parameters. The process controller receives signals with the device before he or she is likely to use such 

indicative of process measurements made by the field diagnostic or calibration features of the devices. There are 

devices and/or other information pertaining to the field also other process control tools, such as auto- tuners that can 

devices, uses this information to implement a control routine be used to correct poorly tuned loops within a process 

and then generates control signals which are sent over the 25 control network. Again, however, it is necessary to identify 

buses to the field devices to control the operation of the a poorly operating loop before such auto-tuners can be used 

process. Information from the field devices and the control- effectively. Similarly, there are other, more complex, diag- 

ler is typically made available to one or more applications nostic tools, such as expert systems, correlation analysis 

executed by the operator workstation to enable an operator tools, spectrum analysis tools, neural networks, etc. which 

to perform any desired function with respect to the process, 30 use process data collected for a device or a loop to detect 

such as viewing the current state of the process, modifying problems therein. Unfortunately, these tools are data inten- 

the operation of the process, etc. sive and it is practically impossible to collect and store all of 

In the past, conventional field devices were used to send the high speed data required to implement such tools on each 

and receive analog (e.g., 4 to 20 milliamp) signals to and process control device or loop of a process control system in 

from the process controller via an analog bus or analog lines. 35 anv kind of systematic manner. Thus, again, it is necessary 

These 4 to 20 ma signals were limited in nature in that they to identify a problem loop or a device before being able to 

were indicative of measurements made by the device or of effectively use these tools. 

control signals generated by the controller required to con- Still further, each device or function block within a smart 

trol the operation of the device. However, in the past decade process control network typically detects major errors that 

or so, smart field devices including a microprocessor and a 40 occur therein and sends a signal, such as an alarm or an 

memory have become prevalent in the process control event, to notify a controller or a host device that an error or 

industry. In addition to performing a primary function within some other problem has occurred. However, the occurrence 

the process, smart field devices store data pertaining to the of these alarms or events does not necessarily indicate a 

device, communicate with the controller and/or other long-term problem with the device or loop that must be 

devices in a digital or combined digital and analog format, 4s corrected, because these alarms or events may be generated 

and perform secondary tasks such as self-calibration, in response to (or be caused by) other factors that were not 

identification, diagnostics, etc. A number of standard and a result of a poorly performing device or loop. Thus, the fact 

open smart device communication protocols such as the that a device or a function block within a loop generates an 

HART®, PROFIBUS®, WORLDFIP®, Device-Net®, and alarm or event does not necessarily mean that the device or 

CAN protocols, have been developed to enable smart field 50 loop has a problem that needs to be corrected. On the other 

devices made by different manufacturers to be used together hand, many devices can have problems without the problem 

within the same process control network. rising to the level of severity to be detected as an alarm or 

Moreover, there has been a move within the process an event, 

control industry to decentralize process control functions. To initially detect problems within the process control 

For example, the all-digital, two -wire bus protocol promul- 55 system, a process control operator or technician generally 

gated by the Fieldbus Foundation, known as the FOUND A- has to perform a manual review of data generated within a 

TION™ Fieldbus (hereinafter "Fieldbus ") protocol uses process control system (such as alarms and events, as well 

function blocks located in different field devices to perform as other device and loop data) to identify which devices or 

control operations previously performed within a centralized loops are operating sub-optimally or are improperly tuned, 

controller. In particular, each Fieldbus field device is capable 60 This manual review requires the operator to have a great deal 

of including and executing one or more function blocks, of expertise in detecting problems based on raw data and, 

each of which receives inputs from and/or provides outputs even with such expertise, the task can be time-consuming at 

to other function blocks (either within the same device or best and overwhelming at worst. For example, an instru- 

within different devices), and performs some process control mentation department of even a medium-sized operating 

operation, such as measuring or detecting a process 65 plant may include between 3,000 and 6,000 ficld devices 

parameter, controlling a device or performing a control such as valves and transmitters. In such an environment, the 

operation, such as implementing a proportional-derivative- instrument technician or control engineer responsible for a 
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process area simply does not have the time to review the control system. This saves time on the part of the operator 

operation of all the field device instrumentation and control and does not require the operator to have a great deal of 

loops to detect which loops or devices may not be operating expertise in detecting problem loops and devices. Also, upon 

properly or may have some problem therein. In fact, because detecting a problem, the diagnostic tool may recommend the 

of limited manpower, the only devices usually scheduled for 5 use of further tools to pinpoint and/or correct the problem, 

maintenance are those that have degraded to the point that which enables the operator to correct problems without 

they dramatically impact the quantity or quality of the having to guess as to which tool is the most appropriate in 

product being produced. As a result, other devices or loops any given situation. Besides saving time, this function 

which need to be retuned or which otherwise have a problem reduces the burden on the operator and helps to assure that 

therein that could be corrected using the tools at hand are not 10 the proper diagnostic tools are used in each circumstance, 
corrected, leading to the overall degraded performance of 

the process control system. BRIEF DESCRIPTION OF THE DRAWINGS . 

SUMMARY OF THE INVENTION- ^ \* a Wock diagram of a process control system in 

which a diagnostic tool can be used; 

A diagnostic tool for use in a process control system 15 FIG. 2 is a block diagram of a process control system of 

automatically collects and stores data pertaining to the FIG. 1 illustrating the configuration of two process control 

different function blocks of devices and loops within the loops run in conjunction with a diagnostic tool; 

system, processes that data to determine which function FIG. 3 is a block diagram of a function block having a 

blocks, devices, or loops have problems that may result in variability indication generator therein; 

the reduced performance of the process control system, and A . . c . 

., .-t. c *u -is j- *• FIG. 4 is a block diagram of a routine implemented by a 

then may suggest the use of other, more specific diagnostic ,. . , . & ,. / i 

♦ i ♦ a *u i a \ .u ui tu a- diagnostic tool to perform diagnostics in the process control 

tools to further analyze and correct the problem. The diag- f c r Tr , 0 J T j -i 

. ♦i a . . ui 'a * c i system of FIGS. 1 and 2; 

nostic tool may detect problems or identify poorly perform- } 

ing devices or loops using a variability indication, a mode FIG 5 is a firsl example screen display generated by the 

indication, a status indication or a limit indication associated 25 diagnostic tool used in the process control system of FIGS, 

with each of the function blocks or devices within a process * anc * ^ 

control system. The variability indication is preferably deter- FIG. 6 is a second example screen display generated by 

mined or partially determined by each function block within the diagnostic tool used in the process control system of 

the process control system to provide a statistical measure- FIGS. 1 and 2; 

ment of the deviation of a parameter associated with the 30 FIG. 7 is a third example screen display generated by the 

device or function block from a set point or other value diagnostic tool used in the process control system of FIGS, 

associated with the device or function block. The mode 1 and 2; and 

indication identifies the mode in which a function block or FIG. 8 is a block diagram of the controller and operator 

device is operating, e.g., a normal mode or a non-normal workstation of FIGS. 1 and 2, illustrating trending commu- 

mode, to indicate if the device or function block is operating n i cations associated with a diagnostic tool, 
in its designed mode. The status indication identifies the 

quality of a signal associated with the function block or DESCRIPTION OF THE PREFERRED 

device at any given time. The limit indication may identify EMBODIMENTS 

if a function block signal is limited in nature. D r • ,„ . CT ~ * t , oi . • 1A 

& 40 Referring now to FIG. 1, a process control system 10 

The diagnostic tool may determine which function blocks, includes a process controller 12 connected to a host work- 
devices or loops have problems associated therewith based stal j on or computer 13 (which may be any type of personal 
on the instantaneous values or on a compilation of the computer or workstation) having a display screen 14 and 
historical values of one or more of the variability indication, connected to field devices 15-22 via input/output (I/O) cards 
the mode indication, the status indication, the limit indica- 45 2 6 and 28. The controller 12, which may be by way of 
tion or other data associated with each function block or example, the DeltaV™ controller sold by Fisher-Rosemount 
device. Thereafter, the diagnostic tool may report detected Systems, Inc., is communicatively connected to the host 
problems to an operator via a display screen and/or may computer 13 via, for example, an ethernet connection and is 
generate written reports (such as printed reports) or elec- communicatively connected to the field devices 15-22 using 
tronic reports sent, for example, over the internet (e.g., 5Q any desired hardware and software associated with, for 
through E-mail) to concerned persons. example, standard 4-20 ma devices and/or any smart com- 

Furthermore, upon detecting problems within one or more munication protocol such as the Fieldbus protocol. The 

process control devices or loops, the diagnostic tool may controller 12 implements or oversees a process control 

suggest the proper tool(s) to be used to further pinpoint the routine stored therein or otherwise associated therewith and 

problem and/or to correct the detected problem. If requested 55 communicates with the devices 15-22 and the host computer 

to do so, the diagnostic tool executes these further tools on 13 to control a process in any desired manner, 

a host workstation to enable an operator to perform further The field devices 15-22 may be any types of devices, such 

diagnostic functions. In cases where the diagnostic tool a s sensors, valves, transmitters, positioners, etc. while the 

requires the use of further data intensive tools to diagnose or 1/0 cards 26 and 28 may be any types of I/O devices 

pinpoint a specific problem (such as an expert system or a 60 conforming to any desired communication or controller 

correlation analysis tool), the diagnostic tool may automati- protocol. In the embodiment illustrated in FIG. 1, the field 

cally configure the host system to collect the data needed to devices 15-18 are standard 4-20 ma devices that conimu- 

run that further tool. nicate over analog lines to the I/O card 26 while the field 

In this manner, the diagnostic tool identifies the function devices 19-22 are smart devices, such as Fieldbus field 

blocks, devices, loops, etc. which need attention without 65 devices, that communicate over a digital bus to the I/O card 

requiring an operator to review massive amounts of data 28 using Fieldbus protocol communications. Generally 

pertaining to numerous devices and loops within a process speaking, the Fieldbus protocol is an all-digital, serial, 
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two-way communication protocol that provides a standard- 
ized physical interface to a two-wire loop or bus that 
interconnects field devices. The Fieldbus protocol provides, 
in effect, a local area network for field devices within a 
process, which enables these field devices to perform pro- 
cess control functions (using function blocks) at locations 
distributed throughout a process facility and to communicate 
with one another before and after the performance of these 
process control functions to implement an overall control 
strategy. It will be understood that, while the Fieldbus 
protocol is a relatively new all-digital communication pro- 
tocol developed for use in process control networks, this 
protocol is known in the art and is described in detail in 
numerous articles, brochures and specifications published, 
distributed, and available from, among others, the Fieldbus 
Foundation, a not-for-profit organization headquartered in 
Austin, Texas. As a result, the details of the Fieldbus 
communication protocol will not be described in detail 
herein. Of course, the field devices 15-22 could conform to 
any other desired standard(s) or protocols besides the Field- 
bus protocol, including any standards or protocols devel- 
oped in the future. 

The controller 12 is configured to implement a control 
strategy using what are commonly referred to as function 
blocks, wherein each function block is a part (e.g., a 
subroutine) of an overall control routine and operates in 
conjunction with other function blocks (via communications 
called links) to implement process control loops within the 
process control system 10. Function blocks typically per- 
form one of an input function, such as that associated with 
a transmitter, a sensor or other process parameter measure- 
ment device, a control function, such as that associated with 
a control routine that performs PID, fuzzy logic, etc. control, 
or an output function which controls the operation of some 
device, such as a valve, to perform some physical function 
within the process control system 10. Of course hybrid and 
other types of function blocks exist. Function blocks may be 
stored in and executed by the controller 12, which is 
typically the case when these function blocks are used for, 
or are associated with standard 4-20 ma devices and some 
types of smart field devices, or may be stored in and 
implemented by the field devices themselves, which is the 
case with Fieldbus devices. While the description of the 
control system is provided herein using function block 
control strategy, the control strategy could also be imple- 
mented or designed using other conventions, such as ladder 
logic. 

The left side of the controller 12 illustrated in FIG. 2 
includes a schematic representation of interconnected func- 
tion blocks 30, 32, and 34 making up an example process 
control loop 36 configured to use the standard 4-20 ma 
devices 17 and 18. Because the function blocks 30, 32 and 
34 are related to the operation of 4-20 ma devices, these 
function blocks are stored in and executed by the controller 
12. In a preferred embodiment, in which a Delta V controller 
is used, the function blocks 30, 32 and 34 are configured to 
be similar to, that is, to use the same or similar protocol, as 
Fieldbus function blocks. However, this convention is not 
necessary as other function block configurations could be 
used instead. As illustrated in FIG. 2, the function block 30 
is an analog input (AI) function block that provides a 
measurement made by, for example, the transmitter (sensor) 
device 17, to the function block 32. The function block 32 
is a PID function block that performs calculations using any 
desired PID strategy and delivers a control signal via a link 
to the function block 34, which is preferably an analog 
output (AO) function block. The AO function block 34 
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communicates with, for example, the valve device 18 to 
cause the valve 18 to open or close according to the control 
signal from the PID function block 32. The AO function 
block 34 also delivers a feedback signal, which may be 
indicative of the position of the valve 18, to the PID function 
block 32, which uses this feedback signal to generate the 
control signal. The controller 12 includes a device interface 
38 (which may be implemented in the controller 12 or in the 
I/O device 26 of FIG. 1) to communicate with the devices 
15-18 to get measurements made thereby and to deliver 
control signals thereto according to the control loop 36 or 
other control loops. The device interface 38 systematically 
receives signals from the devices 15-18 and delivers these 
signals to the proper function block within the controller 12 
associated with the sending device. Likewise, the device 
interface 38 systematically delivers control signals from 
function blocks within the controller 12 to the proper field 
devices 15-18. 

The right side of the controller 12 in FIG. 2 illustrates a 
sample control loop 40 implemented using Fieldbus func- 
tion blocks 42, 44 and 46 located down within the Fieldbus 
field devices 19 and 22. In this instance, the actual function 
blocks 42, 44, and 46 are stored in and executed by the field 
devices 19 and 22 and communicate their associated 
attributes to shadow function blocks 42S, 44S and 46S 
(illustrated as dotted-line boxes) within the controller 12. 
The shadow function blocks 42S, 44S and 46S are set up 
according to the function block configuration used by. the 
controller 12 but mirror the state of the actual function 
blocks 42, 44 and 46, respectively, so that it appears to the 
controller 12 that the actual functions associated with the 
function blocks 42, 44 and 46 are being executed by the 
controller 12. The use of shadow function blocks within the 
controller 12 enable the controller 12 to implement a control 
strategy using function blocks stored in and executed within 
the controller 12 as well as within field devices. Of course, 
the controller 12 can implement control loops having both 
standard function blocks (like function blocks 30, 32 and 34) 
and shadow function blocks therein. For example, the PID 
shadow function block 44S, associated with the actual 
function block 44 in the valve positioner 22, could be linked 
to the AI function block 30 and the AO function block 34 to 
form a process control loop. The creation and implementa- 
tion of shadow function blocks is not the subject of the 
present invention and is described in more detail in U.S. 
patent application Ser. No. 09/151,084 entitled "A Shadow 
Function Block Interface for Use in a Process Control 
Network," filed Sep. 10, 1998, which is assigned to: the 
assignee of the present invention and the disclosure which is 
hereby expressly incorporated by reference herein. 

In one embodiment of the present invention, the controller 
12 includes a diagnostic data collection unit 48 which may 
be, for example, a short term memory that collects and stores 
certain kinds of data associated with each of the function 
blocks (or shadow function blocks) of the process control 
system 10 for use in detecting problems with those function 
blocks, or the devices or loops associated with those func- 
tion blocks. The data collection unit 48 may, for example, 
collect and store a variability indication, a mode indication, 
a status indication and/or a limit indication for each of the 
function blocks within the process control network 10. If 
desired, the data collection unit 48 may perform some 
processing on the collected data as described below. The 
data collection unit 48 periodically sends the collected or 
processed data to the operator workstation 13 via the eth- 
ernet connection for storage in a long term memory or 
historian 50 and for use by a diagnostic tool 52 located at 



4/14/05, EAST Version: 2.O.1.* 



US 6,298,454 Bl 

7 8 

least partially within the operator workstation 13. The diag- lates a variability indication over each evaluation period 

nostic tool 52, which is preferably implemented in software (e.g., over a predetermined amount of time or number of 

stored in a memory of the operator workstation 13 and execution cycles) and, after each evaluation period, sends 

executed by a processor 54 of the operator workstation 13, the calculated variability indication to the data collection 

detects problems within the process control system 10, 5 device 48 within the controller 12 or to the data historian 50 

reports these problems and suggests tools for use in further within the operator workstation 13. This variation indication 

analyzing and correcting these problems. If desired, portions may be, for example, the variability index given above or 

of the diagnostic tool software can be executed within the may be subparts thereof which can be used to determine the 

controller 12 or even within the field devices. variability index given above. If the function blocks are 

The diagnostic tool 52 systematically detects problems 1Q Fieldbus function blocks located within one of the field 

using one or more operating parameters of the function devices 19-22, then the variability indication may be sent to 

blocks or devices within the process control system 10 the controller 12 using asynchronous communications, 

including, for example, a variability parameter, a mode While the final variability index for each function block 

parameter, a status parameter and a limit parameter deter- could be completely calculated by the controller 12 or the 

mined by (or associated with) each of the function blocks or operator workstation 13, this would require each function 

devices within the process control network 10. An indication 15 block to send data to such devices after every execution 

of the variability parameter can be calculated or otherwise cycle (typically on the order of every 50-100 milliseconds), 

determined for each device or function block within the which would require a lot of additional communications 

process control system (whether those function blocks are over the buses of the process control network 10; To 

implemented within the controller 12 or down within one of eliminate this additional communication, it is preferable to 

the field devices 19-22) to indicate the error between two 20 design each function block to calculate a variability indica- 

parameters of the function block. These two parameters may tion therefor and then send this variability indication over 

be different signals associated with the function block or the communication buses once every evaluation period, 

may be two different measurements of the same signal. For which will typically be on the order of once every minute, 

example, for AI function blocks, the variability indication ten minutes or more. Currently, no known standard function 

may indicate the error between a statistical measure (such as 25 blocks provide this capability and, therefore, it should be 

the mean, median, etc.) of the measurement made by a added to the function blocks used within the process control 

sensor over a predetermined amount of time and the actual system 10. 

or instantaneous value of the measurement. Similarly, for an In one embodiment, the calculations for a final variability 

AO function block, the variability indication may be calcu- index associated with a function block are split between the 

lated based on the differences between a historical statistical 30 function block and the diagnostic tool 52. In particular, 

state of a device over a predetermined amount of time (such because the computation of the variability index takes 

as the average location of the valve in a valve device) and computing resources, the most computationally consuming 

the current state of the device (such as the current location parts of these calculations are done in the workstation 13 or 

of the valve). For control function blocks, such as PID, ratio, the controller 12. For this discussion, the calculations for a 

fuzzy logic function blocks and the like, the variability 35 variability index for input and output blocks will be referred 

indication may be based on a deviation of a process param- to simply as a variability index (VI) while the variability 

eter input to the function block and a set point or target index for control function blocks will be 10 referred to as a 

provided to the function block for that parameter. control index (CI). The VI (which is used for input blocks, 

In one embodiment, a variability index may be deter- output blocks and control blocks in manual mode) and the CI 

mined as the integrated absolute error (IAE) over a particu- (which is used for control blocks in auto mode) can be 

lar interval, such as a ten minute evaluation period. In such calculated by the workstation 13 or the controller 12 as 

a case, the variability index can be calculated as: follows: 

M ,„f Pf(0-5| (1) 45 W-I-ili - {2) 

,A£ 'Zj Jv S ™ +s 



wherein: 



wherein: 

N=the number of samples in the evaluation period; 50 
X(i)=the value of the ith sample of the desired function 

block parameter, such as the input to the function block S^mimmum standard deviation expected with feedback 

for AI blocks and control blocks; and control; 
S=the statistical or target value of the parameter to which S^-actual measured standard deviation; and 

the function block parameter is compared, e.g., the set 55 S=sensitivity factor used to make the calculations stable. 

point (for control blocks), the average value of the $i q mav De calculated as: 

function block parameter over the last evaluation 

period (for AI blocks), etc. j rs^t,] 2 . (4) 

If the variation between the X and S variables of equation (1) s ^ = -W* J 2 - 1 — — J 

is Gaussian in nature, then the IAE is equal to the standard 60 
deviation times the square root of the product of two over pi. 
Of course, any other variability indication could be used in wherein: 

addition to or instead of the IAE calculation described above S e<J/wfc =estimated capability standard deviation (standard 
and, thus, the variability indication is not confined to that of deviation at process ideal operation), 

equation (1). 65 A small bias value s is added to the S capab and S tot values 
Preferably, each function block, and especially those in equations (2) and (3) because it has been discovered that, 
located within the field devices 19-22, automatically calcu- if the disturbance to noise signal ratio (i.e., the low fre- 
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quency to high frequency disturbance ratio) is too high, the wherein MR is the average moving range, which may be 
VI and CI calculations give too high of values. Fast sam- calculated as: 
pling with very small differences between consecutive mea- 
surements also attributes to this problem. The bias value s, MR 1_ y ^ _ ^ ; (8) 

it has been found, makes the computations stable. The 5 " N - 1 ^2 
recommended bias value s is 0.1% of the measurement range 

(approximately the measurement accuracy). It will be under- „, , . . t . 

, , t - , ,^ ™ , , . r To reduce computations, only the summing component 

stood that a valve of zero for the VI or CI calculaUons of associaled wilh ^ mae and MR ^ be done during each 

equations (2) and (3) is the best case while a value of one is 10 execution cycle of the function block. The division of the 

the worst case. However, these or other variability indices sum by N or N-l can be done as part of the S tot and S capab 

could be calculated so that a value of one (or even some calculations once every N executions (i.e., once every evalu- 

other value) is the best case. ation period). From the above formulas it is evident that: 

If desired, a percent improvement (PI) value can be 

established for the control blocks as 100 times the CI value 15 s lal = 1.25 * i * Errors [ (9) 

for the control block. 

To perform the above VI, CI and PI calculations in the 1 * Dctr^ : (10) 

most efficient manner possible, each of the function blocks = N ~ \ 12 g 

in, for example, the DeltaV environment or the Fieldbus 20 

environment may calculate the S caDab and S tot values as . , „ ■ . , . . ' . 

. A . t . A 1 #u 1 ■ ui . .u wherem the Error a& - and the Delta fl& _ are the summations in 

variability indications and make these values visible to the t - t£ \ . tS\ *• 1 j 1 i , j 

„ * , . , , , * , V „ , * / equaUons (6) and (8) respectively and are calculated on an 

controller 12, which can then calculate the VI and CI values ongoing basis durfng cach cxccution cycle of the fu^Uon 

using equations (2) and (3) or can provide the S capab and S, of block. 

values to the diagnostic tool 52 in the workstation 13 which 25 Of course, the quality of the input to the function block 

can calculate the VI and CI values. The intermediate calcu- used in these calculations is important and, thus, it is 

lations needed to determine the S b and S tot values will be desirable to only use data that has good status and data;that 

performed each execution of the function block and the fe not Smiled. When using Fieldbus or DeltaV function 

S w6 and S,„ values will be updated once every N execu- bto <**' ^ mode variable takes the status of the PV set point 

capao 101 , ' 30 and BackCalibration variables into account, and so the mode 

tions of the function block (i.e., once every evaluation . . , , , t ., , 4 . r 

x . • l o variable can be used to assure proper calculations for the 

period). In one implementation, the S capab and S tor values variability index. For example, in the OOS (out of service) 

may be updated after 100 executions of the function block. mode> me s ^ and s ^ variables are not determined but 

The total standard deviation can be calculated in the are, instead, set to the best case valve (e.g., zero) to prevent 

function block using the so-called moving time window 35 the detection of an error. On warm starts, if the mode 

computation as follows: changes from OOS to any other mode, the S to[ and S capab 

variables can be set to zero (a best case value), the scan 

s tot m\.2$ mae (5) counter can be reset and the Error fl&y and Data ofciy variables 

of equations (9) and (10) can be set to zero. Also,: the 

wherein MAE is the mean absolute error calculated as: previous values of y and y st should be reset. 

FIG. 3 illustrates a function block 55 having an input 56, 

N an output 57 and a variability indication generator 58 

MAE= — J]\{y{t)-y*\ connected to the input 56. If desired the variability indica- 

N r=i tion generator 58 may be additionally or alternatively con- 

nected to the output 57 and/or to other parts of the function 
45 block 55 to receive other function block parameters or 

and wherein: signals (these connections being illustrated by doited lines in 

N»the number of executions in an evaluation period; FIG. 3). If the function block 55 is, for example a control 

r function block, the variability index calculator 58 receives 

y(t)=the value of the t'th instantaneous sample of the the input 56 (which may be the process value that is being 

desired function block parameter, such as the input to 50 controlled by the loop in which the control block 55 

the function block; and operates) and compares that input to a set point previously 

y =the statistical or target value of the parameter to which supplied to the function block 55. The variability indication 

the function block parameter is compared, e.g., the & enerator ^ e tern T u e the ^ ariabilit y M ™ according 

i **u c *• ill i . t0 equation (1) and send that index to a communicator 59 

average or mean value of the ftinction block parameter ^ ^ ^ variabmt indication tQ tfae u 

over the last evaluation period. every evaluation period (every N samp i es ). However, as 
Generally speaking, the process value (PV) of the func described above, the variability indication generator 58 may 
tion block will be used in the I/O blocks to calculate y sr In determine the S rot and S b values in the manner described 
control blocks, either the working setpoint or the PV will be above and send these values to the controller 12 or work- 
used as Yj, depending on the block mode. station 13, which can determine the VI and/or CI values 
The capability standard deviation, S capab , can be calcu- 60 therefrom. If the function block 55 is a function block being 
lated as follows: ^ executed within the controller 12, the controller 12 could 

include a separate routine to determine the variability indi- 

MR _ cation for each function block, as no bus communications 

Scapab ■ j-f2g would need to take place after each sample interval. The 

65 communicator 59 can be any standard communication unit 
associated with a function block or a communication pro- 
tocol. 
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A second function block operating parameter that may be 
used to determine problems within the process control 
system 10 is an indication of the mode in which each of the 
function blocks (or loops or devices) is operating. In the case 
of Fieldbus function blocks, as well as some other known 
function blocks, each function block has a mode parameter 
that is available to the controller 12 to indicate the mode in 
which the function block is operating. From this mode 
indication, a data analyzer within the diagnostic tool 52 can 
determine a value of the mode parameter to indicate if the 
function block (and thereby the loop, module or device) is 
operating in its desired or designed mode or, alternatively, if 
something has occurred to cause the function block (device 
or loop) to operate in a different, less preferable mode. 
Fieldbus function blocks operate in one of a number of 
modes. For example, AI function blocks operate in an 
out-of-service mode (wherein an operator may have put the 
device out-of-service to perform maintenance), a manual 
mode in which some signal, such as an output of the function 
block, is being set manually instead of based on the designed 
operation of the function block, and an automatic mode, in 
which the function block is operating in a normal manner, 
i.e., the way in which it was designed to operate. Fieldbus 
control blocks can also have one or more cascade modes 
wherein the mode is controlled by other function blocks or 25 
by an operator. Typically, Fieldbus function blocks have 
three modes variables associated therewith at any given time 
including a target mode, which is the mode in which the 
operator has set the block to operate (which can be other 
than the normal or automatic mode), an actual mode, which 
is the mode in which the control block is actually operating 
at any given time, and a normal mode, which is the mode in 
which the function block was designed to operate and is 
associated with the normal operation of the function block. 
Of course, these or other mode indications may be used as 
desired. 

The mode indication may be periodically provided to the 
controller 12 and/or to the operator workstation 13. If the 
function block is within the controller 12, the mode indica- 
tion for each function block may be provided to the data 
collection unit 48 at any desired time or interval. For 
Fieldbus function blocks or other function blocks within the 
field devices, the controller 12 may periodically request the 
mode parameters for each function block using a ViewList 
request (in the Fieldbus protocol). If desired, the data 
collection unit 48 within the controller 12 may store the 
mode at each sampling period or evaluation period and 
provide the stored data to the data historian 50. Thereafter, 
the diagnostic tool 52 may determine mode values indicating 
when or how long the function block spent in the different 
modes or in a normal mode (or a non-normal mode) or 
indicating what percent of a specific time period the function 
block was in a normal mode (or a non-normal mode). 
Alternatively, the data collection unit 48 or some other 
specifically designed unit within the controller 12 could 
detect when each function block is out of its normal mode 
(by, for example, comparing the function block's normal 
mode with its actual mode at any given time). In this case, 
the data collection unit 48 could communicate the mode of 
any function block by indicating when changes in the mode 
took place or are detected, which reduces the amount of 
communication needed between the controller 12 and the 
operator workstation 13. 

A status parameter is another function block operating 
parameter that may be used to detect problems within 
process control devices and loops. A status indication pro- 
vided by each function block may define or identify the 
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status of the primary value (PV) associated with the function 
block or device. In addition or alternatively, one or more of 
the inputs and outputs of a function block may have a status 
indication associated therewith. Fieldbus function blocks 
have a status parameter associated therewith which can take 
on the form of "good", "bad" or "uncertain" to indicate the 
status of the function block PV, inputs and/or outputs. A 
status indication may also identify or include a limit 
indication, such as the limits associated with the PV or other 
function block parameter. Thus, for example, the limit 
indication may indicate whether the PV of the function block 
is high or low limited. Again, the diagnostic tool 52 may 
determine status values or limit values indicating when, how 
long or what percent of a specific time period the status of 
the function block was a normal status (or a non-normal 
status), and when, how long or what percent of a specific 
time period a function block variable was at one or more 
limits (or not at the one or more limits), or was a bad status 
or a questionable status. 

Similar to the mode indication, the status indication and 
the limit indication may be sent by each function block to the 
controller 12 periodically or on request (using, for example, 
the ViewList command in the Fieldbus protocol) [and 
changes therein may determined by the controller 12 and 
sent to the operator workstation 13. Alternatively, the status 
and limit indications may be sent to the operator workstation 
13 without being processed. If desired, the function blocks 
may be set up to communicate mode, status and/or limit 
indications only when changes therein actually take place, 
which further reduces the amount of communications 
between the controller 12 and the function blocks within 
field devices. However, when using this communication 
scheme, the current state of all the required parameters is 
needed to establish a base against which to compare 1 the 
changes when the diagnostic tool 52 is first placed on line. 
This current state may be measured or collected by haying 
the controller 12 periodically report parameter values (even 
though they have not changed) or by having the diagnostic 
tool 52 cause the controller 12 to report parameters defined 
for exception reporting. Based on the status of each of the 
function blocks, the diagnostic tool 52 can quickly identify 
measurements which are bad, and need attention (uncertain 
status) or which have been incorrectly calibrated because 
they have a measurement or PV that is limited. Of course, 
the status and limit indications may take on one of any 
different number and types of values, depending on the type 
of system in which they are being used. 

Furthermore, a status indication may be used for any 
different variables (other than the PV) of a function block, 
device or loop. For example, in a control loop haying 
feedback control, the status of the feedback variable may be 
used to detect problems within function blocks and loops. 
The status of this feedback variable (e.g., the back calibra- 
tion or BackCal variable for control or actuator function 
blocks in the Fieldbus protocol), or any other variable, can 
be examined by the diagnostic tool 52 to detect when a 
function block has an output that is limited by, for example, 
a downstream function block or other downstream condi- 
tion. Similar to the mode indication, the controller 12 may 
detect and store actual status values or may store changes in 
the status values as the status indication. 

Other data associated with a process control function 
block, device or loop may be used to detect problems as 
well. For example, the operator workstation 13 (or? the 
controller 12) may receive, store and review events: and 
alarms generated by the devices or function blocks within 
the process control network 10. In, for example, the Fieldbus 
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environment, function blocks support a block error param- blocks, devices, loops or other entities within the process 

eter that reports abnormal processing conditions detected by control network 10. Generally speaking, the software routine 

a transducer or a function block. Fieldbus devices reflect any 60 collects data pertaining to each of the function blocks 

problem that is detected by the device or function block within a process, such as variability indication, mode 

using one of 16 defined bits in a block error bitstream sent 5 indications, status indications, limit indications, alarm or 

to the controller 12. Fieldbus devices report the first detected event information, etc., on an ongoing basis as the process 

problem to the controller 12 as an event or alarm and these is running and detects the existence of problem 

events or alarms can be forwarded by the controller 12 to an measurements, calculations, control loops, etc. based on the 

operator workstation 14 event journal. In one embodiment, collected data. The software routine 60 may send a report or 

the diagnostic tool 52 analyzes or reviews the 6th bit of the 10 create a display listing each detected problem and its eco- 

block error parameter (in the Fieldbus protocol) to detect nomic impact on plant operation when configured or 

when a device needs maintenance soon and, thus, when a requested to do so. When viewing a display of the detected 

condition exists that must be addressed but which is not problem loops on, for example, the display 14 of: the 

currently limiting device operation. Similarly, the diagnostic operator workstation 13, an operator can select a particular 

tool 52 analyzes the 13th bit of the block error parameter (in 15 problem for review or correction. The software routine 60 

the Fieldbus protocol) to determine when correct device then suggests and may automatically implement other diag- 

operation is not possible because of a condition detected by nostic tools to further pinpoint the problem or to correct the 

the device and, thus, immediate action is required. Of problem. In this manner, the diagnostic tool 52 processes 

course, other events, alarms, other bits within the block error data generated by the function blocks or devices of a process 

parameter or other types of error indications may be used by 20 control system, automatically recognizes problems based on 

the diagnostic tool 52 to detect problems associated with the the data and then suggests and executes other diagnostic 

operation of the process control network 10, and such other tools to further pinpoint the cause of the problem and to 

events, alarms etc. may be associated with the Fieldbus correct the problem. This saves the operator enormous 

protocol or any other desired device or controller protocol. amounts of time and effort in detecting and correcting 

In some instances, function blocks may have parameters, 25 problems within a process control system and also helps to 

such as mode or status parameters that are set to other than assure that the appropriate diagnostic tools (which may not 

normal or good for reasons unrelated to the correct operation be totally familiar to the operator) are used to correct the 

of the process or loop in which these function blocks problem. 

operate. For example, in batch processes, when a batch is not A block 62 of the routine 60 receives and stores : the 

being run, the modes of the function blocks used within that 30 variability, mode, status, limit, alarm, event and other data 

process are set to non-normal values. However, it would be used to detect problems within devices, blocks and loops of 

undesirable to detect these non-normal mode (or status) the process control system 10 on an ongoing basis, i.e., 

indications and identify problems with the system based whenever the process is running. Preferably, mis data is 

thereon because the batch process is designed to have down stored in the data historian 50 within the operator worksta- 

times. It is preferable, therefore, to provide each function 35 lion 13. Alternatively, however, this data could be stored in 

block (or the module or loop in which it is run) with an any other desired memory, such an in a memory associated 

application state parameter indicating if the function block with the controller 12. Likewise, this data may be sent to the 

(or module) is purposely in a non-normal mode, or has a bad operator workstation 13 in any format and may be sent as 

status. In other words, the application state parameter will compressed data, if so desired. 

indicate when alarming or problem detection for the tunc- 40 A block 63 detects or determines when an analysis of the 

tion block should be prevented. For function blocks used in data is to be performed because, for example, a periodic 

batch processes, for example, the application state parameter report is to be generated or because a user is requesting such 

will be set to one value to indicate when the function blocks an analysis. If no analysis is to be performed, the block 62 

are operating to perform a batch run application and will be simply continues to collect data and may process that data to 

set to another value to indicate when the function blocks are 45 determine values for the function block operating param - 

purposely not being used to perform a normal function cters. If an analysis is to be performed, a block 64 analyzes 

within a batch run application and so no detection of the stored data or stored parameter values to determine 

problems should be based on the operations of these func- which function blocks, devices or loops may be having 

tion blocks at these times. Such an application state param- problems. Generally speaking, the data may be analyzed 

eter is illustrated in FIG. 3 to be communicated to the 50 based on the current or instantaneous values of the function 

controller 12 via the communicator 59. The controller 12 block operating parameters, or may be analyzed on a his- 

and/or operator workstation 13 may detect the application torical basis to determine which function blocks, devices or 

state parameter for each function block and ignore data . loops are having problems over a specific period of time, 

(such as variability, mode, status and limit data) associated The historical analysis helps to detect problems that are long 

with function blocks that are in the second category, e.g., 55 term in nature based on the performance over a specified 

that are purposely set to non-normal or bad states, in order period of time. To detect a problem, the block 64 may, if 

to prevent false alarms. Of course, there are other reasons necessary, calculate a variability index from the variability 

that the application state parameter may be set to prevent indications supplied by the function blocks and then com- 

detection of problems besides the down time associated with pare the variability index to a specific range or limit (which 

batch processes. 60 may be set by the operator) to see if either the instantaneous 

The diagnostic tool 52 is preferably implemented in value of, or some statistical measure of the historical value 

software within the operator workstation 14 and, if (such as the average or median value) of the variability index 

necessary, some parts may be implemented in the controller is outside of the range or above or below the specified limit 

12 and even down within the field devices, such as the field for a function block. If so, a problem may exist and the 

devices 19-22. FIG. 4 illustrates a block diagram of a 65 function block, device or loop associated with the out-of- 

software routine 60 that may be executed in the operator range variability index is listed as having a problem to be 

workstation 14 to detect and help correct problem function corrected. 
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Likewise, the block 64 may compare the actual mode of 
a function block or device with the normal mode of mat 
function block or device to see if they match. As indicated 
above, the controller 12 may perform this function and send 
indications of the result, or of mismatches to the historian 
50. If desired, however, the operator workstation 13 may 
perform these comparisons directly. Using the historical 
data, the block 64 may determine loop utilization, i.e., the 
percent of time that the loop (or function block) operated in 
the designed (normal) mode. In the instantaneous analysis, 
the function block, loop or device may be considered to have 
a problem when it is currently not operating in the designed 
or normal mode. 

Similarly, the block 64 may analyze the status and limit 
indications) of each function block to determine when the 
status is bad or uncertain or otherwise not a designed or 
normal status or when a function block signal is at a limit. 
A historical analysis may calculate or determine if a par- 
ticular function block has a status indication that is bad or 
uncertain for a predetermined percentage of a specified 
amount of time, may determine which PVs or other variables 
reached a limit or stayed at a limit for a predetermined 
percentage of a specified amount of time, or may analyze the 
status indication or limit indication in any other manner to 
determine if a problem exists within the function block or 
device or loop in which a function block is located. 
Likewise, the block 64 may determine, in an instantaneous 
evaluation, which function blocks, devices or loops have 
status values that are currently not in the designed or normal 
state and/or which signals or variables have reached a limit 
(i.e., are value limited). The block 64 may review the alarm 
and event notifications to see if any devices need 
maintenance, either now or in the future. The blocks which 
exceed the variability or control index limits and the blocks 
which have an active bad, limited, or mode condition will be 
identified and temporarily saved. This summary information 
can support the creation of "current" summary display. The 
instantaneous values and conditions can be integrated by the 
diagnostic tool 52 on, for example, an hour, shift and daily 
basis to obtain the average value of variability index and the 
percent improvement and the percent time the bad status, 
limited signal or non-normal mode condition existed. Of 
course, the block 64 may perform other types of processing 
on the variability, mode, status, limit, event, alarm and/or 
any other desired data to detect problems. Furthermore, the 
block 64 may run the analysis using different limits, ranges, 
historical times, etc., all of which may be set by a user or an 
operator. 

For function blocks used in, for example, batch mode 
processes, data associated with times when a function block 50 
intentionally was not operating is discarded or not used in 
the analysis based on the application state parameter for the 
function block. 

After the block 64 has detected the problems within the 
process control network, a block 66 determines if any 
written or electronic reports should be generated because, 
for example, periodic reports have been requested by a user. 
If so, a block 68 creates a report listing the problem function 
blocks, devices, loops, etc. and their economic effect on the 
process control system. Such an economic impact may be 
determined by having an operator or other user specify the 
dollar amount associated with each percentage point of 
reduced operation of the process or a loop in the process. 
Then, when a loop is found to have a problem, the actual 
performance of the process loop may be compared to a 
known optimum performance value to determine the per- 
centage difference. This percentage difference is then mul- 
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tiplied by the specified dollar amount to percentage point 
ratio to determine the economic impact in terms of dollars. 
The report may be printed out on a printing device, dis- 
played on a computer screen (such as the display 14) or other 
electronic display, sent to a user via E-mail, the Internet or 
any other local area or wide area network, or may be 
delivered to a user in any other desired manner. If desired, 
the diagnostic tool 52 may be configured to automatically 
notify a plant maintenance system whenever a problem loop 
is detected and this notification can be sent to the mainte- 
nance system as an event using the event/alarm capability of 
the known OPC interface. 

A block 70 determines if an operator has requested an 
analysis to be performed at the workstation 13 and, if so, a 
block 72 enters a display or dialog routine that enables a user 
to find out different information related to the problem or to 
select different parameters for performing the analysis. In 
one embodiment, an operator or other person that uses the 
diagnostic tool 52 is presented with a dialog when he or she 
logs onto the workstation 13. The dialog summarizes the 
conditions that need to be addressed in the system without 
identifying the loops that are the source of the problem. The 
dialog may convey the information in a graphical format 
such as on screen display 80 as shown in FIG. 5, The screen 
display 80 summarizes the percent of total input, output or 
control function blocks in the process or plant that currently 
violate the default limits set for utilization (mode), limited 
signals, bad status or high variability. Because multiple 
conditions may exist in a single block, the total could 
potentially exceed 100%. If the total exceeds 100 percent, 
then the percent for each category can be scaled so that the 
total equals 100 percent. Modules that have input, output, or 
control blocks that violate the preset limits are summarized 
in a tabular list 82. In FIG. 5, module FIC101 has one or 
more function blocks operating in undesigned modes , and 
one or more function blocks with high variability, while the 
module LIC345 has one or more function blocks with; bad 
status. 

More information about the nature of the problems, such 
as the limits associated with the function blocks, can be 
shown graphically by, for example, clicking on a module 
name within the list -82. Furthermore, by selecting a filter 
button 84 on the screen of FIG. 5, the user may be presented 
with a dialog allowing the user to select a summary time 
frame, the types of blocks to be included in the summary and 
the limit for each category or block. Such a dialog screen 86 
is illustrated in FIG. 6, where the limits for the mode, 
limited, and bad status of input blocks are set at 99 percent 
utilization and where the limit for the variability index for 
input blocks is set at 1.3. In this case, the percent utilization 
of a block is determined as the percent of a specific time 
period in which the mode or status is normal and a function 
block signal was not limited. However, the limits could also 
be set as the percent of time that the mode or status was 
non-normal or a function block variable was at a limit, in 
which case the limits should be set closer to zero. Of course, 
by choosing all of the loop selections within the screen 86, 
all modules that include an input, output or control block 
will be included in the summary. 

A Timeframe box 88 of the screen 86 can be manipulated 
by changing the setting therein to alter the historical time 
frame for which the analysis is performed. For example, by 
choosing a "Now" selection within the Timeframe box 88, 
the instantaneous or current value of the block parameters 
are used to determine if each module will illustrated as a 
problem module in the summary list 82. While any time 
frame may be specified, some example time frames that can 
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be used in filtering are the Current Hour or Last Hour, a user to choose how many and which tests should be used 

Current Shift or Last Shift, Current Day or Last Day, etc. For (and must be failed) before a process control condition is 

these time frames, a module is included in the summary list identified as having a problem associated therewith, 

only when a detected condition is present for a significant Referring again to FIG. 4, when a user selects one of the 

portion (i.e., a predetermined portion) of the selected time 5 function blocks in, for example, the display 90 of FIG. 7, a 

frame as defined by the limit condition. block 93 detects the selection of the problem function block 

If desired, the user may change the limit values used for and a block 94 displays a set of options to be used to correct 

variability index, either per block or on a global basis. To the problem block or loop. For example, for control blocks, 

facilitate setting variability limits, the user may select the the diagnostic tool 52 may allow the user to use an autotuner 

desired limit to be changed and then may be provided with 10 or other tuner to tune a loop or may allow the user to perform 

a choice of either editing that limit for a particular block or trend analysis on the loop. By selecting the autotuner option, 

of setting that limit for all of the blocks simultaneously. the diagnostic tool 52 automatically finds and executes the 

When the user wants to set the variability limit for all of the autotuner application for the selected control block or loop, 

blocks together, the user is presented with a dialog box that However, when the trend option is selected, the workstation 

allows the variability limit to be set to the current value of 15 13 will begin to collect trending data as describe hereinafter, 

a variability plus a specified bias provided by the user. Of For input or an output function blocks, the block 94 may 

course, the limits for variability, mode, status and limited allow the user to, for example, use a further diagnostic tool 

variables may be applied to all of the function blocks within for that block or to perform trend analysis. If, for example, 

a module, an area, a system, or any other logical unit and the selected input or output block is within a Fieldbus or 

may all be changed in a similar manner. Default limits may 20 Hart device, then selecting the diagnostics option will acti- 

be initially provided for a configuration as 1.3 for variability vate the diagnostic application for the associated transducer 

index and 99% utilization for mode, limited and status block using tools known in the art such as any device 

indications. Of course, these default values may be changed calibration tools. In a Delta V environment, the asset man- 

from the module summary display as described above. agement solutions (AMS) diagnostic tool manufactured and 

By selecting a module name within the summary 82 of 25 sold by Fisher-Rosemount can be used for this purpose to 

FIG. 5, the user can be provided a dialog screen having communicate with a device, to obtain specific information 

further details related to that module. Such a dialog screen therewith and to implement diagnostics associated with the 

90 is illustrated in FIG. 7, for the module FIC101 using the device. Of course, other tools or recommendations could be 

Last Shift time frame. The screen 90 illustrates the perfor- made as well. For example, for transmitter problems, or 

mance of a PID1 block and an AH block within the FIC101 30 function blocks associated with transmitters, the block 94 

module. The information provided in the screen 90 allows may recommend that a device calibration be used to cali- 

the user to easily identify the particular measurement, brate the transmitter while, for a valve, any of the valve 

actuator, or control block that caused the module to be diagnostic routines can be used to detect and possibly 

included in the summary and the percent time that the correct the specific problem within the valve. Generally 

condition was detected. In particular, the percent of time of 35 speaking, the recommendations made by the block 94 may 

the last shift that a block was in its normal mode, normal be determined based on whether the problem falls into one 

status and not limited is illustrated in FIG. 7 as loop of a number of predetermined types of problems, the nature 

utilization. Of course, the screen of FIG. 7 could be con- or identity of the source of the problem (e.g. whether it 

figured to illustrate the percent of time during the last shift originated in a control or input function block, a transmitter 

that a block was in a non-normal mode, or had a non-normal 40 or a valve, etc.) or any other desired criteria. Of course, any 

status or the percent of time in the last shift that a function desired diagnostic tools can be used, including those how 

block variable was at one or more limits. A measure of known or those developed in the future, 

variation is shown for the blocks illustrated in FIG. 7 along If the specific nature of the problem is not easily detected 

with limits therefor. The variability measure in this case is from the variability, status, mode, limit or other data ;that 

calculated so that a value of one is the best case and values 45 pointed to the existence of a problem, the block 94 can 

greater than one indicate more and more variability error. recommend the use of other, more complex diagnostic tools, 

However, using the CI and VI calculations of equations (2) such as plotting routines, correlation (such as auto- 

and (3) for the variability index will cause the variability correlation and cross-correlation) routines, spectrum analy- 

index to be between zero and one, with zero being the best sis routines, expert analysis routines or any other desired 

case. In this case, the variability limit should be set to be 50 routine or tools provided for the process control system 10. 

between zero and one. Furthermore, the percent improve- Of course, the diagnostic tool 52 may recommend or suggest 

ment (PI) that is possible in a control loop is illustrated in the use of more than one tool and allow the operator to 

FIG. 7 for control blocks, namely the PID1 block. If desired, choose which tool should be used in any situation, 

the percent utilization values that fall below (or above) the Furthermore, the block 94 may limit its suggestions to tools 

respective limits can be highlighted or otherwise marked to 55 actually available within the process control network 1 10, 

indicate the detected problem(s). e.g., those loaded onto the operator workstation 13, or may 

Of course, any other screen display may be used to suggest tools that would have to be purchased or loaded into 

summarize which loops, devices, function blocks or mea- the process control system 10 before being used. Of course, 

surements have a high variability index (such as being the block 94 can also suggest the use of manual tools, i.e., 

greater than a user specified limit), operate in a non-normal 60 those which are not run on the operator workstation 13, 

mode or have process measurements that have bad or controller 12 or one of the devices 15-28. 

uncertain status or that are limited. As noted above, using an After the block 94 recommends one or more further 

historical analysis, the diagnostic tool 52 may provide diagnostic tools, a block 96 waits for a user to select a tool 

displays for a specified time frame to identify devices, loops for implementation, and, upon receiving such an instruction 

or function blocks that have a variability index, mode, status 65 from the operator, a block 98 finds and executes the selected 

or limit variable that has changed significantly from its tool to enable the operator to further analyze and pinpoint 

normal value. Of course, the diagnostic tool 52 may enable the cause of the problem or to fix the problem. After 
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implementing the diagnostic tool, a block 100 enables the 
operator to select a different tool for the selected problem 
and a block 102 enables the operator to select a different 
problem. 

In one embodiment, the block 94 can recommend analysis 
tools typically referred to as trending applications that 
require the collection of a relatively large amount and/or a 
lot of samples of data before being able to be run. Examples 
of such trending applications include a correlation analysis, 
a neural network, a fuzzy logic control procedure, an adap- 
tive tuning procedure, a spectrum analysis routine, etc. 
Unfortunately, when the diagnostic tool 52 detects problems, 
the data required for the trending tool is typically unavail- 
able because this data was not previously collected. This 
data may be needed to be collected at a high frequency data 
rate that is not practically achievable using simple commu- 
nications between the controller 12 and the workstation 13. 
As a result, when the operator selects a tool that requires the 
collection of this data (fast data), the block 98 may auto- 
matically configure the controller 12 to collect the necessary 
data from the process control system 10. 

When such data needs to be collected from Fieldbus 
function blocks or devices, i.e., from the devices via the 
Fieldbus bus, the controller 12 may use one or more Field- 
bus trend objects to collect the data, may bundle and store 
the collected data as packets of data, and may then send the 
packets of data to the operator workstation 13 at any desired 
time so that the fast data is delivered to the operator 
workstation 13 in a non-time critical manner. This operation 
reduces the communication load between the controller 12 
and the operator workstation 13 for the collection of this 
data. Typically, a trend object is set up to collect a prede- 
termined number of samples (e.g., 16) of any desired data 
pertaining to a function block and, when the predetermined 
number of samples has been collected, these samples are 
communicated to the controller 12 using asynchronous 
communications. The use of one or more trend objects 110 
for Fieldbus function blocks is illustrated in FIG. 8. The 
trend object(s) 110 are used to collect and send desired data 
to the data collection device 48 within the controller 12 and 
originate within the actual function blocks down within the 
Fieldbus devices. These trend objects 110 may be provided 
by the Fieldbus device or by the shadow function blocks 
(illustrated generally as shadow function blocks 112S in 
FIG. 8) within the controller 12. Similarly, for function 
blocks located within and executed by the controller 12 
(illustrated generally as function blocks 113 in FIG. 8), 
virtual trend objects 114 can be set up within the controller 
12 to collect the desired data delivered from the 4—20 ma (or 
other devices). Samples for such virtual trend objects 114 
may be collected at any desired rate, such as every 50 
milliseconds. The virtual trend objects 114 may be config- 
ured to be similar to the actual trend objects of the Fieldbus 
protocol and are delivered to the data collection device 48. 
The data collection device 48 delivers the collected data to 
the data historian 50 within the operator workstation 13 as 
noted above. 

The trend objects 110 and 114 are collected until enough 
data has been stored to run the desired diagnostic tool. After 
enough fast data has been collected, the block 98 of FIG. 4 
executes or otherwise implements the further diagnostic tool 
using the collected data so as to perform high level process- 
ing and loop analysis. 

While the diagnostic tool 52 has been described as being 
used in conjunction with Fieldbus and standard 4—20 ma 
devices, it can be implemented using any other external 
process control communication protocol and may be used 
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with any other types of function blocks or devices having 
function blocks therein. Moreover, it is noted that the use of 
the expression "function block" herein is not limited to what 
the Fieldbus protocol or the DeltaV controller protocol 
identifies as a function block but, instead, includes any other 
type of block, program, hardware, firmware, etc., associated 
with any type of control system and/or communication 
protocol that can be used to implement some process control 
function. While function blocks typically take the form of 
objects within an object oriented programming environment, 
mis need not be case. 

Although the diagnostic tool 52 described herein is pref- 
erably implemented in software, it may be implemented in 
hardware, firmware, etc., and may be implemented by any 
other processor associated with tie process control system 
10. Thus, the routine 60 described herein may be imple- 
mented in a standard multi-purpose CPU or on specifically 
designed hardware or firmware as desired. When imple- 
mented in software, the software routine may be stored in 
any computer readable memory such as on a magnetic disk, 
a laser disk, or other storage medium, in a RAM or ROM of 
a computer or processor, etc. Likewise, this software may be 
delivered to a user or a process control system via any 
known or desired delivery method including, for example, 
on a computer readable disk or other transportable computer 
storage mechanism or over a communication channel such 
as a telephone line, the internet, etc. (which are viewed as 
being the same as or interchangeable with providing such 
software via a transportable storage medium). 

Thus, while the present invention has been described with 
reference to specific examples, which are intended to be 
illustrative only and not to be limiting of the invention, it 
will be apparent to those of ordinary skill in the art that 
changes, additions or deletions may be made to the disclosed 
embodiments without departing from the spirit and scope of 
the invention. 

What is claimed is: 

1. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
function block operating parameter; and an output 
generator that creates a report indicating the detected 
problem, 

wherein the function block operating parameter is a 
variability parameter and wherein the data analyzer 
determines a variability value associated with one of 
the function blocks at each of the number of times 
based on collected function block operating parameter - 
data. 

2. The diagnostic tool of claim 1, wherein the detector 
compares the variability value with a variability limit to 
detect the problem. 

3. The diagnostic tool of claim 1, wherein the variability 
value is indicative of an integral squared error between a first 
function block parameter and a second function block 
parameter. 
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4. The diagnostic tool of claim 3, wherein the first 
function block parameter is a statistical value of a process 
control parameter and the second function block parameter 
is an instantaneous value of the process control parameter. 

5. The diagnostic tool of claim 1, wherein the one of the 
function blocks is associated with an input device that 
measures a process parameter and wherein the variability 
value for the one of the function blocks comprises an 
indication of an error between a statistical value of the 
measured process parameter and an instantaneous value of 
the measured process parameter. 

6. The diagnostic tool of claim 1, wherein the one of the 
function blocks uses a process parameter signal and a set 
point to produce a control signal and wherein the variability 
value for the one of the function blocks comprises an 
indication of an error between the process parameter and the 
set point. 

7. The diagnostic tool of claim 1, wherein the function 
block operating parameter data comprises the variability 
value. 

8. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
function block operating parameter; and 

an output generator that creates a report indicating the 
detected problem, 

wherein the function block operating parameter is a mode 
parameter and wherein the data collection unit receives 
a mode indication for each of the function blocks. 

9. The diagnostic tool of claim 8, wherein the data ^ 45 
analyzer determines a mode value for one of the function 
blocks specifying if the one of the function blocks is in a 
normal mode in which the one of the function blocks was 
designed to operate during normal operation. 

10. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
function block operating parameter; and 
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an output generator that creates a report indicating the 
detected problem, 

wherein the function block operating parameter is a status 
parameter and wherein the data collection unit receives 
status indications for each of the multiplicity of func- 
tion blocks. 

11. The diagnostic tool of claim 10, wherein the data 
analyzer determines a status value from the status indica- 
tions indicating if a status associated with one of the function 
blocks is a normal status associated with the normal opera- 
tion of the one of the function blocks. 

12. The diagnostic tool of claim 10, wherein the data 
analyzer determines a status value for one of the function 
blocks as a percentage of a specific period of time that the 
status of the one of the function blocks was a non-normal 
status associated with the one of the function blocks. 

13. The diagnostic tool of claim 12, wherein the detector 
compares the status value for the one of the function blocks 
to a status limit to detect the problem. 

14. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
function block operating parameter; and 

an output generator that creates a report indicating the 
detected problem, 

wherein the function block operating parameter is a limit 
parameter and the data collection unit collects limit 
indications associated with a function block variable. 

15. The diagnostic tool of claim 14, wherein the data 
analyzer determines a limit value from the limit indications 
indicating if the function block variable is at one or more 
limits. 

16. The diagnostic tool of claim 14, wherein the data 
analyzer determines a limit value as a percentage of a 
specific period of time that the function block variable was 
at one or more limits. 

17. A diagnostic tool for use in a process control system . 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
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function block operating parameter, wherein the detec- 
tor detects the problem based on a plurality of past 
values for the function block operating parameter for 
one of the function blocks; and 
an output generator that creates a report indicating the 5 
detected problem. 

18. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks adapted to control a 
process device during operation of a process, the diagnostic 
tool comprising: 10 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 15 
function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
limes during operation of the process control system 2Q 
based on the received function block operating param- 
eter data; 

a detector that detects a problem within the process 
control system based on the determined values of the 
function block operating parameter, wherein the detec- 2 5 
tor detects the problem based on a plurality of values of 
the function block operating parameter over a particular 
time and further including a communicator that enables 
the particular time to be specified by the user; and 

an output generator that creates a report indicating the 30 
detected problem. 

19. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 
comprising: 35 

a computer readable memory; and 

a routine stored on the computer readable memory and 

adapted to be implemented on the processor, wherein 

the routine: 

collects data pertaining to a function block operating 40 
parameter for each of a number of times during the 
operation of the process control system based on the 
collected function block operating parameter data; 

detects a problem within the process control system 
based on the determined values of the fiinction block 45 
operating parameter; and 

produces a report that lists the detected problem, 

wherein the function block operating parameter is a 
variability parameter and wherein the routine collects 5Q 
variability indications for each of the multiplicity of 
function blocks. 

20. The diagnostic topi of claim 19, wherein the routine 
determines a variability value for one of the function blocks 
from the variability indications collected from the one of the 55 
function blocks and compares the variability value to a 
variability limit to detect the problem. 

21. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 6Q 
comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory and 
adapted to be implemented on the processor, wherein 
the routine: 65 
collects data pertaining to a function block operating 
parameter for each of a number of times during the 



operation of the process control system based on the 

collected function block operating parameter data; 
detects a problem within the process control system 

based on the determined values of the function block 

operating parameter; and 
produces a report that lists the detected problem, 
wherein the function block operating parameter is a mode 
parameter and wherein the routine collects mode indi- 
cations for each of the multiplicity of function blocks. 

22. The diagnostic tool of claim 21, wherein the routine 
determines a mode value for one of the function blocks as a 
percentage of a specific period of time that the one of the 
function blocks was in a non-normal mode associated with 
the one of the function blocks. 

23. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 
comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory and 

adapted to be implemented on the processor, wherein 

the routine: 

collects data pertaining to a function block operating 
parameter for each of a number of times during the 
operation of the process control system based on the 
collected function block operating parameter data; 
detects a problem within the process control system 
based on the determined values of the function block 
operating parameter; and 
produces a report that lists the detected problem, : 
wherein the function block operating parameter is a status 
parameter and wherein the routine collects status indi- 
cations for each of the multiplicity of function blocks. 

24. The diagnostic tool of claim 23, wherein the routine 
determines a status value for one of the function blocks as 
a percentage of a specific period, of time that a status 
associated with the one of the function blocks was a hon- 
normal status. 

25. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 
comprising: 

a computer readable memory; and 

a routine stored on the computer readable memory -and 

adapted to be implemented on the processor, wherein 

the routine: 

collects data pertaining to a function block operating 
parameter for each of a number of times during the 
operation of the process control system based on the 
collected function block operating parameter data; 

detects a problem within the process control system 
based on the determined values of the function block 
operating parameter; and 

produces a report that lists the detected problem, ; 
wherein the function block operating parameter is a limit 

parameter and the routine collects limit indications 

associated with a function block variable. 

26. The diagnostic tool of claim 25, wherein the routine 
determines a limit value from the limit indications as a 
percentage of a specific period of time that the function 
block variable was at one or more limits. 

27. A method of diagnosing problems in a process control 
system that uses a multiplicity of function blocks to control 
the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to function block operation 
parameter from each of the multiplicity of function 
blocks during operation of the process control system; 
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determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; and 

detecting a problem within the process control system 
based on the determined function block operating 
parameter values; 

reporting the detected problem to a user, 

wherein the function block operating parameter is a 
variability parameter and the step of collecting data 
includes the step of collecting variability indications for 
each of the multiplicity of function blocks. 

28. The method of claim 27, further including the step of 
calculating first and second variability indications in each of 
the function blocks as the function block operating param- 
eter data, wherein the step of collecting includes the step of 
sending the first and second variability indications from each 
of the function blocks to a data analyzer and further includ- 
ing the step of calculating a value of the variability param- 
eter for each of the function blocks in the data analyzer. 

29. A method of diagnosing problems in a process control 
system that uses a multiplicity of function blocks to control 
the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to function block operation 
parameter from each of the multiplicity of function 
blocks during operation of the process control system; 
determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; 

detecting a problem within the process control system 
based on the determined function block operating 
parameter values; and 

reporting the detected problem to a user, 

wherein the function block operating parameter is a mode 
parameter and the step of collecting data includes the 
step of collecting mode indications for each of the 
multiplicity of function blocks. 

30. The method of claim 29, wherein the step of deter- 
mining includes the step of determining a mode value for 
one of the function blocks as a percentage of a specific 
period of time that the one of the function blocks was in one 
of a normal or a non-normal mode associated with the 
operation of the one of the function blocks and the step of 
detecting includes the step of comparing the mode value for 
the one of the function blocks to a mode limit. 

31. A method of diagnosing problems in a process control 
system that uses a multiplicity of function blocks to control 
the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to function block operation 
parameter from each of the multiplicity of function 
blocks during operation of the process control system; 

determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; 

detecting a problem within the process control system 
based on the determined function block operating 
parameter values; and 

reporting the detected problem to a user, 

wherein the function block operating parameter is a status 
parameter and the step of collecting data includes the 
step of collecting status indications for each of multi- 
plicity of function blocks. 
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32. The method of claim 31, wherein the step of deter- 
mining includes the step of determining a status value for 
one of the function blocks as a percentage of a specific 
period of time that the status of the one of the function 

5 blocks was one of a normal status or a non-normal status 
associated with the one of the function blocks and the step 
of detecting includes the step of comparing the status value 
for the one of the function blocks to a status limit. 

33. A method of diagnosing problems in a process control 
10 system that uses a multiplicity of function blocks to control 

the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to function block operation 
parameter from each of the multiplicity of function 
15 blocks during operation of the process control system; 
determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; 
detecting a problem within the process control system 
based on the determined function block operating 
parameter values; and 
reporting the detected problem to a user, 
25 wherein the function block operating parameter is a limit 
parameter related to whether a function block variable 
is at one or more limits and the step of collecting data 
includes the step of collecting limit indications for each 
of the multiplicity of function blocks. 
30 34. The method of claim 33, wherein the step of deter- 
mining includes the step of determining a limit for one of the 
function blocks as a percentage of a specific period of time 
that the function block variable is at the one or more limits 
and the step of detecting includes the step of comparing the 
35 limit value for the one of the function blocks to a limit value 
limit. 

35. A function block adapted to control a process in a 
process control system and for execution by a processor in 
a process control environment, comprising: 

40 a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first function block 
signal is associated with an operation of the first 

45 routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 

5Q block signal, 

wherein the function block is an input function blockj the 
first signal is indicative of a process parameter mea- 
surement and wherein the second routine compares a 
statistical measurement of the first signal to an instan- 

5S taneous measurement of the first signal to determine the 
variability indication. 

36. The function block of claim 35, wherein the statistical 
measurement of the first signal is a mean. 

37. A function block adapted to control a process in a 
60 process control system and for execution by a processor in 

a process control environment, comprising: 
a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
65 ment a process operation, wherein a first function block 
signal is associated with an operation of the first 
routine; and 
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a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 
block signal, 

wherein the function block is a control function block that 
uses a process parameter signal and a set point to 
produce a control signal and wherein the second routine 
compares the process parameter signal and the set point 
to determine the variability indication. 

38. A function block adapted to control a process in a 
process control system and for execution by a processor in 
a process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first function block 
signal is associated with an operation of the first 
routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 
block signal, 

wherein the variability indication is indicative of the 
integral squared error between the first signal and 
another value associated with the function block. 

39. A function block adapted to control a process in a 
process control system and for execution by a processor in 
a process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first function block 
signal is associated with an operation of the first 
routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 
block signal, 

wherein the second routine calculates a new value for the 
variability indication after each of a plurality of execu- 
tions of the first routine. 

40. A function block adapted to control a process in a 
process control system and for execution by a processor in 
a process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first function block 
signal is associated with an operation of the first 
routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 
block signal, 

wherein the variability indication is based on a calculation 
of the mean absolute error of the first signal. 

41. A function block adapted to control a process in a 
process control system and for execution by a processor in 
a process control environment, comprising 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first function block 
signal is associated with an operation of the first 
routine; and 
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a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on the first function 
block signal, 

wherein the variability indication includes a variability 
indicative of an actual total standard deviation associ- 
ated with the first signal and a second variability value 
indicative of a capability standard deviation associated 
with the first signal. 

42. A function block for execution on a processor as part 
of a process control application within a process control 
environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation as part of the process control 
application; and 

a state variable that is set to a first state when the process 
control application is using the function block in an 
attempt to perform the process operation and is set to a 
second state when the process control application is not 
using the function block in an attempt to perform the 
process operation. 

43. The function block of claim 42, wherein the function 
block is a Fieldbus function block and includes a commu- 
nication unit that communicates the state variable over a 
Fieldbus bus using a Fieldbus protocol. 

44. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks, the diagnostic tool 
comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, a first variability indication indicative 
of a mean absolute error of a function block operating 
parameter and a second variability indication indicative 
of a moving range average of a function block operat- 
ing parameter for each of the multiplicity of function 
blocks; 

a data analyzer that determines a variability value asso- 
ciated with one of the function blocks for each of a 
number of times during operation of the process control 
system based on the first variability indication and the 
second variability indication; 

a detector that detects a problem within the process 
control system based on the determined variability 
value; and 

an output generator that creates a report indicating the 
detected problem. 

45. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks, the diagnostic tool 
comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, a first variability indication indicative 
of an actual total standard deviation of a function block 
operating parameter and a second variability indication 
indicative of a capability standard deviation associated 
with the function block operating parameter for each of 
the multiplicity of function blocks; 

a data analyzer that determines a variability value asso- 
ciated with one of the function blocks for each of a 
number of times during operation of the process control 
system based on the first variability indication and the 
second variability indication; 
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a detector that detects a problem within the process 
control system based on the determined variability 
value; and 

an output generator that creates a report indicating the 
detected problem. 

46. The diagnostic tool of claim 45, wherein the data 
analyzer combines the first variability indication with the 
second variability indication to produce the variability 
value. 

47. The diagnostic tool of claim 46, wherein the data 
analyzer adds a sensitivity value to each of the first and 
second variability indications to produce the variability 
value. 

48. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks, the diagnostic tool 
comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, a mode indication for each of the 
multiplicity of function blocks; 

a data analyzer that determines a mode value for one of 
the function blocks as a percentage of a specific period 
of time that the mode of the one of the function blocks 
was a non-normal mode based on received mode indi- 
cation; 

a detector that detects a problem within the process 
control system based on the determined mode value; 
and 

an output generator that creates a report indicating the 
detected problem. 

49. The diagnostic tool of claim 48, wherein the detector 
compares the mode value for the one of the function blocks 
to a mode limit to detect the problem. 

50. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks, the diagnostic tool 
comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks and an application state parameter for 
each of the multiplicity of function blocks; 

a data analyzer that determines a value for the function 
block operating parameter for each of a number of 45 
times during operation of the process control system 
based on the received function block operating param- 
eter data; 

a detector that ignores the function block operating 
parameter based on function block operating parameter 
data associated with one of the multiplicity of function 
blocks when the function block parameter data is 
associated with a time in which the application state 
parameter was in a first state and that uses the function 
block operating parameter based on function block 
operating data associated with the one of the multiplic- 
ity of function blocks to detect a problem within the 
process control system when the function block param- 
eter data is associated with a time in which the appli- 
cation state parameter was in a second state; and 

an output generator that creates a report indicating the 
detected problem. 

51. A diagnostic tool for use in a process control system 
having a multiplicity of function blocks, the diagnostic tool 
comprising: 

a data collection unit configured to communicate with 
each of the multiplicity of function blocks to receive, 
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on a regular basis during operation of the process 
control system, data pertaining to a function block 
operating parameter for each of the multiplicity of 
function blocks; 
a data analyzer that determines a value for the function 
block operating parameter for each of a number of 
times during operation of the process control system 
based on received function block operating parameter 
data; 

a detector that detects a problem within the process 

control system based on the determined values of the 

function block operating parameter; 
a recommendation unit that recommends use of a further 

tool to correct the detected problem; and 
an output generator that creates a report indicating the 

detected problem. 

52. The diagnostic tool of claim 51, wherein the recom- 
mendation unit recommends the use of a tuner. 

53. The diagnostic tool of claim 51, wherein the recom- 
mendation unit recommends the use of a calibrator. 

54. The diagnostic tool of claim 51, wherein the recom- 
mendation unit implements the recommended further tool. 

55. The diagnostic tool of claim 51, wherein the further 
tool requires collection of process parameter data of a 
process parameter and further including a further data col- 
lection unit that automatically collects samples of the pro- 
cess parameter as the process parameter data using a trend 
object during operation of the process control system. 

56. The diagnostic tool of claim 55, wherein the trend 
object is a virtual trend object created by the further data 
collection unit. 

57. The diagnostic tool of claim 55, wherein the trend 
object is created by one of the function blocks. 

58. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 
comprising: ; 

a computer readable memory; and 

a routine stored on the computer readable memory and 

adapted to be implemented on the processor, wherein 

the routine: 

collects data pertaining to a function block operating 
parameter for each of a multiplicity of function 
blocks on a regular basis during operation of the 
process; 

collects an application state parameter from one of the 
multiplicity of function blocks; 

determines a value for a function block operating 
parameter for each of a number of times during the 
operation of the process control system based on the 
collected function block operating parameter data; 

ignores the function block operating parameter based 
on function block operating parameter data associ- 
ated with the one of the multiplicity of function 
blocks when the function block operating parameter 
data is associated with a time in which the applica- 
tion state parameter was in a first state; 

uses the function block operating parameter to detect a 
problem within the process control system when the 
function block operating parameter is based on func- 
tion block operating parameter data associated with 
the one of a multiplicity of function blocks when the 
function block operating parameter data is associated 
with a time in which the application state parameter 
was in a second state; and 

produces a report which lists the detected problem. 

59. A diagnostic tool for use in a process control system 
that includes a processor and that uses a multiplicity of 
function blocks to control a process, the diagnostic tool 
comprising: 
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a computer readable memory; and 

a routine stored on the computer readable memory and 

adapted to be implemented on the processor, wherein 

the routine: 

collects data pertaining to a function block operating 
parameter for each of a multiplicity of function 
blocks on a regular basis during operation of the 
process; 

determines a value for the function block operating 
parameter for each of a number of times during the 
operation of the process control system based on the 
collected function block operating parameter data; 

detects a problem within the process control system 
based on the determined values of the function block 
operating parameter; 

recommends the use of a further tool to correct the 
detected problem; and 

produces a report which lists the detected problem. 

60. The diagnostic tool of claim 59, wherein the routine 
recommends one of a tuner routine, a calibration routine and 
data analysis routine as the further tool. 

61. The diagnostic tool of claim 59, wherein the routine 
implements the recommended further tool. 

62. The diagnostic tool of claim 59, wherein the routine 
recommends the use of a further tool that requires the 
collection of process parameter data for a process parameter 
and automatically collects samples of the process as the 
process parameter data during the operation of the process 
control system. 

63. A method of diagnosing problems in a process control 
system that uses a multiplicity of function blocks to control 
the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to a function block operating 
parameter from each of a multiplicity of function 
blocks during operation of a process control system; 

collecting an application state parameter from one of the 
multiplicity of function blocks; 

determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; 

ignoring the function operating parameter based on func- 
tion block operating parameter data associated with one 
of the multiplicity of function blocks to detect a prob- 
lem when the function block operating parameter data 
is associated with a time in which the application state 
parameter was in a first state; 

using the function block operating parameter based on 
function block operating parameter data associated 
with one of the multiplicity of function blocks to detect 
the problem when the function block operating param- 
eter data is associated with a time in which the appli- 
cation state parameter was in a second state. 

reporting the detected problem to a user. 

64. A method of diagnosing problems in a process control 
system that uses a multiplicity of function blocks to control 
the operation of a process, the method comprising the steps 
of: 

collecting data pertaining to a function block operating 
parameter from each of a multiplicity of function 
blocks during operation of a process control system; 

determining a value for the function block operating 
parameter for each of a number of times during opera- 
tion of the process control system based on the received 
function block operating parameter data; 

detecting a problem within the process control system 
based on the determined function block operator 
parameter values; 
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automatically recommending the use of a further tool to 

correct the detected problem; and 
reporting the detected problem to a user. 

65. The method of claim 64, further including the step of 
automatically collecting process parameter data during 
operation of the process control system for use by the further 
recommended tool. 

66. A function block for execution by a processor in a 
process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first signal is 
associated with an operation of the first routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication based on a calculation of 
a moving range average associated with the first signal. 

67. A function block for execution by a processor in a 
process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first signal is 
associated with an operation of the first routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication including a first value 
representing a mean absolute error of the first signal 
and a second value representing a moving range aver- 
age of the first signal. 

68. A function block for execution by a processor in a 
process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first signal is 
associated with an operation of the first routine; and 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variability indication (V) computed as: 
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V = {- 



wherein S lq is a minimum standard deviation expected with 
feedback control, S toi is an actual measured standard devia- 
tion and s is a sensitivity factor. 

69. AFieldbus function block for execution by a processor 
in a process control environment, comprising: 

a computer readable memory; 

a first routine stored on the computer readable memory 
and adapted to be executed on the processor to imple- 
ment a process operation, wherein a first signal is 
associated with an operation of the first routine; 

a second routine stored on the computer readable memory 
and adapted to be executed on the processor to deter- 
mine a variabibty indication based on the first signal; 
and 

a communication unit that communicates the variability 
indication over a Fieldbus using Fieldbus protocol. 
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